AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.
Hi everyone, wednesday (28th of October) was a national holiday here in Czech republic (commemorating the creation of standalone Czechoslowakian republic in the 1918). Still, quite a few of us came to the office. The atmosphere was relaxed (even more than usual) and in the afternoon some people played the recently popular Keep talking and nobody explodes game. It is amazing to see how creative people can get (talking about the creators)=) IMHO this project shows a bright side of indie games scene: good idea + good execution => good fun. Back to the Factorio reality=) In the past two weeks we have increased the frequency of the bugfixing releases. There were a few silly bugs that were created while fixing other things. Thanks for bearing with us. The general mood is to just finish the 0.12 so we can get it off our plate. Kovarex + 2 - 3 people are still focused on the 0.12 while others are either wrapping up other smaller tasks or have started working on some 0.13 stuff already.
GUI progress update (kovarex) This is a continuation of the last status report from FFF-269. As it might not be a surprise, the biggest bottleneck of the 0.17 release is the GUI. I like to believe, that we have learned a lot from the pitfalls of the collaborative creative process of GUI. This is the typical way we were redesigning the GUI: Two to three people started discussing what could be cool to change in the particular GUI. Some people randomly joined and left the ongoing discussion. Arguments to discard certain ideas have to be repeated over and over. Then the discussion is ended because of something. A week later people start talking again, most of them forgot most of the stuff, or were discussing it with different people, so they assume some details of the changes to be understood by everyone, while they aren't. They come to an agreement how it should be done. They have a random discussion about it a week later and figure out, they had completely different ideas about how it should be done, they just didn't articulate them precisely. Both are kind of angry to have to reopen and re-negotiate the subject again. Someone starts to implement the GUI, but half-way through it is uncovered, that there was another layer of misunderstanding when specifying how should the work be done, and we need to go to step 1 again and repeat. Since many GUIs are thought and worked on in parallel, these situations overlapped and amplified the problems of mixing things up in our heads about what we agreed on in which GUI. Luckily, we eventually figured out, that it can't be done like this, and since there is a lot of work in the GUI, we need to make a process. It goes like this: First, there is some general discussion about the GUI, all team members can share their ideas. kovarex + Twinsen sit alone in the office, and discuss for some time (can be hours), all the pros and cons of how things should be done, and make some agreement. Twinsen writes a detailed UX document about the GUI containing the structure, and more importantly the behaviour, in a detailed manner. Twinsen + kovarex discuss the UX document and propose changes until they agree on the final version. Albert + Aleš take the UX document and create a UI mockup based on it. kovarex + Twinsen + Albert agree on the UI mockup or propose changes. Someone is assigned to implement the GUI based on the UX document and UI mockup kovarex reviews that the implementation is correct and points out some inconsistencies that he can see. Part of this step is making sure, that we share as many GUI styles and code as possible across different GUIs. kovarex + Albert have a final look on the implementation and fix final details until they both agree that the screen is fully finished. Having the UX documents/UI mockups always available proved to be a huge time saver. Not only it helps us to solve the communication problems, we also don't have to remember and re-articulate decisions from some time ago as we can just open the document and see what we agreed on and instantly continue where we left off. A good part of this strict pipeline is that we now have better knowledge of the state of the work progress. These are the GUI screens that we hope to deliver for 0.17: .header_cell { text-align:center; font-weight: bold; } .finished { text-align:center; font-weight: bold; } .not_finished { text-align:center; font-weight: bold; } .finished_gui_table { border-spacing: 10px; } .finished_gui_table td { border: 1px; border-style:solid; padding: 5px; } General UX UX draft UX review UI mockup UI review Implementation draft Implementation review Final review Load map Save map Graphics settings Control settings Sound settings Interface settings Other settings Map generator Technology GUI Technology tooltip Recipe/item/entity tooltip Action bar Shortcut bar Train GUI Manage/Install mods Main screen chat Recipe explorer Character screen Menu structure New game Help overlay Chat icon selector Blueprint library You can see, that there is still a lot of to do, but the work tends to accelerate as more and more of the GUI layouts/tilesets/standards are being finalized and reused. The conclusion is that 0.17 experimental in January is possible, but it might be February as well :).
Removing RTL language translations Wheybags I'm sorry to say that we have removed the RTL language translations (Hebrew and Arabic) in 0.17.20. Until this point we've had a half implementation of RTL languages, where the text is simply flipped when we download it from Crowdin. This 'works' for a decent proportion of things, but not nearly 100%. In order to attain the level of polish we want for the 1.0 release, we would need to spend a lot of time implementing proper support for RTL layouts. This just doesn't make sense for us given our current goals, and the proportion of our player base which uses these languages (less than 0.1%). We decided that instead of completely gutting the translations, we could leave them in for those who enjoy them, but not to offer them in the GUI as defaults. The languages will remain up on Crowdin, and the locale files will still be present in game, but there will be no option in the in-game language options dialog to choose them. If you want to use an RTL language, you will have to manually edit your config file to set your locale. Detailed instructions are available on our forum. What this also means, is that we won't be investigating any bug reports about RTL issues.
I've done several optimizations around the game update over the past few game versions but in 0.15 I decided to also look at some of the game GUIs. In particular there are 3 GUIs which tend to take a large amount of time when visible: the production stats, the trains view, and blueprint tooltip previews.
Hello, Another week has elapsed, which brings us another week deeper into the declining weather of autumn.
Hello, we are still here, working on the game.
Hello, it feels really nice these weeks. We actually have some time to improve the game instead of just fixing bugs. Lets take a look on some of the improvements.
Hello fellow builders, There is this commotion about the paid mods on Steam. (It had been cancelled already). I understand that the implementation was far from optimal, as people would be suddenly expected to pay for mods that were free until now. It was also sad, that the modders were to get only 25% percent of the money. But I personally think, that there is nothing wrong about the idea generally. If a reasonable price tag on a great mod allows the creator to develop the mod full time, create professional content, and people are willing to pay for it, everyone wins. Free mods would still exist so it would be up to the players to choose. I'm NOT saying we are going to allow paid mods for Factorio anytime soon. But I'm not denying this possibility in the far future.
Offshore pump redesign V453000, Albert As one of the last entities which do not have high resolution graphics, the time has come for the offshore pump. The offshore pump is practically a 1-tile entity, but they must have a 1 tile gap between each other. It is also the only entity placed on a water tile at the moment. When we changed the way how terrain to water transitions work, we moved the offshore pump to be placed on the water tile. This can result in the pump drawing over terrain in ugly ways. With the redesign, we took the oppourtunity to move the offshore back onto land, and additionally the pump checks a 2x3 tile water area in order to be buildable. The new placement rules only applies to newly built pumps. Offshore pumps on existing maps will keep functioning, they’ll just be shifted out from the shore. There is no blue colour for water integration at the tip of the offshore pump, so the offshore pump will look correct even with unexpected water types (not a big problem in vanilla). The water integration is split to an underwater layer which does not show when the pump gets landfilled over. In the basic concept, the offshore pump is another type of a pump, so it should be similar to the other pump entity Albert made a few years ago, including the animation and visible fluid in it. The obvious difference is the connection to water. However we felt that is not different enough and needs more visual balance, so we added a pair of supportive legs. We are planning to release the new offshore pump graphics with the next release, likely next week.
